Altri articoli sul numero 65 Articoli sullo stesso argomento Claudio Casetto si lamenta perche' il suo A1200 con scheda M-Tec 68030 portata a 33Mhz all'avvio ha bisogno di ripetuti reset per partire: le prime volte si blocca subito con un errore di sistema, ma insistendo alla fine l'A1200 si avvia e funziona regolarmente. Claudio Casetto chiede se potrebbe essere colpa del "sovracloccaggio" e se e' possibile disabilitare la scheda collegando due fili e un interruttore al jumper interno. Non ci sono problemi per disabilitare la scheda con un interruttore da collegare ai pin del jumper. Incertezze all'accensione sono tipiche di un overclocking troppo spinto, quando i chip di contorno al processore non reggono la nuova frequenza. Ci sono due meccanismi principali, che si manifestano in situazioni opposte. Molti circuiti servono solo all'accensione o al reset: se sono troppo sollecitati alla prima accensione tutto parte regolarmente (perché sono ancora freddi), ma riaccendendo o resettando l'Amiga non funziona piu' nulla: il chip e' surriscaldato e non e' piu' in grado di svolgere la sua funzione. Tuttavia i transistor un po'caldi sono leggermente piu' veloci. Puo' succedere che un circuito che funziona marginalmente non abbia velocita' sufficiente appena acceso, ma scaldandosi recuperi quel che basta a partire: potrebbe essere questo il caso di Claudio Casetto. I circuito incriminato non e' necessariamente sulla M-Tec, potrebbe anche essere nell'alimentatore (l'assorbimento di corrente dei circuiti dipende dalla temperatura) o nell'hard disk. L'ultimo caso si manifesta con una certa frequenza negli A1200 accelerati: l'aumento di velocita' altera il ciclo di attesa dell'hard disk durante il boot, il Kickstart 3.0 si confonde e provoca un errore di sistema. Altre volte puo' succedere che l'hard disk cambi con l'eta' il suo tempo di avvio, con identico risultato: se il problema e' questo, basta cambiare l'hard disk con uno realmente compatibile Amiga o ridurre il clock dell'acceleratrice. Una cosa da tenere sempre presente quando si fa overclocking e' che si perde la garanzia Motorola sulla correttezza dei risultati dei calcoli del microprocessore. Questo e' particolarmente vero per i coprocessori: e' difficile che si blocchino del tutto, piu' spesso sbagliano qualche cifra meno significativa del risultato. Purtroppo anche questa lettera, come quelle di troppi altri lettori, e' priva di una descrizione completa del computer perché chi l'ha scritta ha scelto un approccio sbagliato alla soluzione del suo problema. E' certamente utile fare qualche ipotesi sulle cause del malfunzionamento e sui possibili metodi per risolverlo, pero' bisogna sempre ricordarsi che lo scopo finale e' quello di risolvere il problema: ci potrebbe essere piu' di una causa da rimuovere o di un rimedio da applicare. Il componente presunto colpevole potrebbe essere provatamente innocente, o il guasto si puo' rendere innocuo. Se ci si fissa su una sola strada si rischia di spendere tempo e fatica affrontando un problema inesistente o aggirabile. Quindi non spedite lettere in cui descrivete minuziosamente il solo componente che credete colpevole (tralasciando il resto perche' "non importa") oppure chiedete come creare l'"anello mancante" dalla vostra personale e dettagliatissima soluzione di un problema lasciato nel vago. Se non ho a disposizione tutti i dati, non posso neanche rispondere a chi si limita a chiedere una conferma delle sue ipotesi. Stefano Bin e' perplesso per il comportamento del suo hard disk Quantum AT-bus. Funzionava tranquillamente, finché non e' stata aggiunta all'A1200 una Viper 68030. Ha iniziato a dare errori di lettura e scrittura, ma solo usando il comando copy della Shell: con Directory Opus tutto funzionava come prima! Comunque, con la sostituzione dell'hard disk il difetto e' sparito (con riduzione di prestazioni). Probabilmente la colpa e' del vecchio hard disk Quantum, che non e' in grado di trasferire in un colpo solo grandi quantita' di dati: la cura al problema e' stata spiegata in dettaglio sul numero 46 di Amiga Magazine e gia' ripetuta sui numeri 53 e 54 . Consiste nello scrivere il numero 0xffff nella casella Maxtransfer di tutte le partizioni, ma solo DOPO aver eseguito la formattazione: per un difetto del Kickstart 3.0, il comando format funziona correttamente solo se il parametro Maxtransfer e' stato lasciato al suo valore originale. A volte il difetto si manifesta sotto forma di dati copiati male, quindi errori di sistema molto frequenti (se a corrompersi e' il codice eseguibile). Senza acceleratrice non si manifestava perche' la scsi.device di A1200 aggiusta i suoi parametri in funzione della potenza di calcolo disponibile: cosi' il multitasking e' migliore, ma cambiando le temporizzazioni cambia anche il comportamento dell'hard disk, e difetti latenti si manifestano. Il problema non si verificava neanche con Directory Opus perche' la sua funzione di copia usa un buffer di appoggio in memoria di piccole dimensioni, riempito da frequenti accessi all'hard disk: il caso ha voluto che fossero di dimensioni inferiori alla soglia che causa perdita dati sull'A1200 di Stefano Bin. Sperimentalmente si nota che Directory Opus e SID usano buffer cosi' piccoli che quasi mai scatta il "bug maxtransfer", pero' e' un metodo molto inefficiente di copiare files. Il comando copy della shell 3.0 o successiva cerca di allocare piu' memoria che puo' e di trasferire i dati in pochi blocchi di grandi dimensioni, per aumentare la velocita' dell'operazione (mediamente e' 2-3 volte piu' veloce di SID). La dimensione della memoria di appoggio si puo' modificare a piacere specificando sulla riga di comando il parametro BUF. Non e' il comando copy ad essere difettoso, ma anzi la sua colpa e' quella di essere l'unico a sfruttare a fondo l'hardware.